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FOREWORD 


This  strategy  document  is  one  of  eight  functional  task  area 
strategies  produced  by  the  STARS  Joint  Task  Force.  All  of  the  docu¬ 
ments  produced  by  the  Task  Force,  including  the  general  STARS  Program 
Strategy  document,  are  listed  in  the  STARS  Joint  Task  Force  Report. 

This  document  identifies  the  scope,  sub-objectives  and  stra¬ 
tegies  designed  to  provide  the  conceptual  approach  for  accomplishment 
of  the  STARS  Program  objectives  in  the  acquisition  functional  task 
area.  It  identifies  and  describes  the  high-level  activities,  pro¬ 
ducts  and  capabilities.  In  order  to  provide  full  understanding, 
background  and  rationale  material  is  sometimes  covered  that  is  also 
in  STARS  Program  Strategy. 

These  functional  task  area  strategy  documents  do  not  attempt  to 
delineate  the  detailed  plans,  costs  and  procedures  for  bringing  the 
proposed  products  and  capabilities  into  being  and  do  not  identify  the 
form  of  the  particular  projects  that  will  undertake  the  work  nor  the 
organizations  in  which  the  work  will  be  accomplished.  Instead,  these 
strategies  are  intended  to  guide  the  process  of  such  implementation 
planning  and  accomplishment. 

Indeed,  because  of  the  high  degree  of  linkage  among  the  func¬ 
tional  task  areas,  implementation  plans  and  acquisitions  may  well 
combine  related  capabilities  and  products  across  areas.  Individual 
projects  may  tackle  only  part  of  one  subtask  from  a  functional  area 
or  several  subtasks  from  several  functional  areas. 

Thus,  this  functional  task  area  strategy  describes  broad, 
achievable  requirements  for  accomplishing  the  relevant  STARS  objec¬ 
tives.  Its  main  purpose  is  to  help  guide  the  implementation  planning 
process. 


Ada&  is  a  Registered  Trademark  of  the  Department  of  the  Defense, 
Ada  Joint  Progrmn  Office. 
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1.0  OVERVIEW 


1.1  Scope  of  Task  Area 

The  scope  of  the  acquisition  task  area  encompasses  the  entire 
spectrum  of  the  acquisition  process  as  applied  to  mission  critical 
computer  resources  including  systems,  software,  and  related  technolo¬ 
gies.  Additionally  it  includes  a  direct  linkage  to  all  of  the  other 
STARS  program  task  areas. 


1 .2  Purpose 

■The  purpose  of  this  task  area  is  to  improve  existing  acquisition 
procedures,  regulations,  business  practices  and  incentives  relating 
to  software  acquisition,  and  to  remove  impediments  in  the  acquisition 
process  currently  hindering  efficient  software  development  and  sup¬ 
port^ 


1 .3/  Goals  and  Objectives 

{  ( 

v--‘The  specific  goals  and  objectives  of  the  Acquisition  Task  Area 
are  the  improvement  of  all  business  and  contract  related  policies  and 
practices,  attainment  of  a  higher  degree  of  uniformity  in  the  appli¬ 
cation  of  acquisition  policies  and  practices;  and  an  improvement  of 
the  tools  associated  with  the  acquisition  of  systems  and  software  in 
order  to  streamline,  simplify  and  accelerate  the  acquisition  process; 
and  to  foster  a  more  effective  DoD  contractor  relationship.  Major 
emphasis  is  to  be  placed  on  computer  software  associated  with  "mis¬ 
sion  critical"  applications  and  embedded  computer  systems,  and  the 
integration  of  this  software  with  the  surrounding  hardware, 

1.4  stms&y 

The  overall  Acquisition  Task  Area  has  been  divided  into  five 
major  task  elements.  Tasks  1,  2  and  5  are  critical  to  the  success  of 
the  acquisition  area  task.  Tasks  are  identified  as  follows: 


1.4.1  Task  1.  Define  Acquisition  Process  and  Identify  Issues 

This  task  should  systematically  identify  opportunities  to 
improve  the  system  acquisition  process.  This  task  would  identify 
specific  issues,  regulations,  solicitation  provisions  and  contract 
clauses  which  impede  or  impact  acquisition  effectiveness  and  timeli¬ 
ness  of  mission  critical  software  acquisition. 

1.4.2  Task  2.  Implement  Acquisition  Improvements 

The  purpose  of  this  task  should  be  to  provide  an  orderly 
approach  for  instituting  both  near-term  and  long-term  improvements  to 
streamline  and  accelerate  the  acquisition  process.  It  would  address 
the  application  of  new  contracting  and  business  approaches  and  new 
technology  to  support  and  improve,  in  the  near  term,  the  acquisition 
process.  This  task  would  provide  a  means  for  incorporating  in  the 
long  term,  new  methods  and  technological  breakthroughs  in  the 
acquisition  of  mission  critical  software  systems.  Recommended 
improvements  resulting  from  the  Task  1  efforts  as  well  as  suggested 
improvements  from  other  sources  within  the 

Government /Industry /Academic  Community  would  be  acted  on  under  this 
task. 

1.4.3  Task  3.  Impact  of  New  Technology  on  Systems 

The  purpose  of  this  task  should  be  to  determine  the  impact  of 
new  technology  on  systems  being  acquired.  This  would  be  a  three-part 
task  focusing  on  current  and  emerging  technology  for  systems  being 
acquired.  The  objective  of  this  task  would  be  to  derive  detailed 
reward/risk  factors;  a  descriptive  summary  of  lessons  learned,  and  a 
model  for  transitioning  software  related  technology  into  acquisition 
programs. 


1*4.4  Task  4,  New  Technology  for  System  Acquisition  Process 

The  objective  of  this  task  should  be  to  survey  and  analyze  the 
potential  impact  that  emerging  technology  may  have  on  improving  the 
acquisition  management  process.  Those  technologies  that  offer  poten- 
tial  savings  and  can  improve  the  process  should  be  implemented  and 
assessed.  The  success/failure  impact  that  the  technology  has  on 
improving  the  system  acquisition  process  should  be  measured  and 
evaluated. 

1*4*5  Task  5.  Establish  a  Software  Acquisition  Panel 

This  task  should  assist  in  establishing  a  Software  Acquisition 
Panel  for  implementing  measures  to  improve  the  Defense  Software 
acquisition  process  and  to  provide  uniform  software  acquisition  poli¬ 
cies  and  procedures  across  the  military  services. 

1.5  Linkage  to  Other  Task  Areas 

Linkages  between  most  of  the  Software  Initiative  Tasks  and 
mutual  impacts  should  be  identified.  Section  3.0  presents  linkages 
between  the  Acquisition  Task  and  these  other  tasks,  as  viewed  by  the 
Chairman,  of  all  other  task  areas  as  a  result  of  the  Raleigh 
Workshop. 
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PLAN  DETAILS 


2.1  A.  Define  Acquisition  Process  and  Identify  Issues  (Task  1) 


2.1.1  Purpose 

The  purpose  of  this  task  would  be  to  systematically  identify 
opportunities  to  improve  the  system  acquisition  process.  The  task 
should  be  structured  into  a  four-step  process  for  identifying 
specific  problems  and  challenges  impacting  on  effective  acquisition 
of  mission  critical  software: 

a.  Review  the  system  acquisition  process  as  implemented  in 
actual  programs  and  policy  guidance  and  regulations  includ¬ 
ing  current  contracting  vehicles  and  incentive  structures. 

b.  Identify  the  specific  activities  within  the  system  acquisi¬ 
tion  process  which  require  and  involve  software  considera¬ 
tion  and  requirements. 

c.  Identify  points  at  which  the  system  acquisition  process 
impacts  software  acquisition  and  life  cycle 

d.  Identify  specific  issues  and  opportunities  to  improve  the 
acquisition  process. 

2. 1.1.1  Subtask  A.l  Definition.  Review  the  system  acquisition 
process  so  as  to  consider  and  understand  the  fundamental  structure 
within  which  mission  critical  software  is  developed  and  acquired. 
The  majority  of  this  software  is  acquired  as  an  integral  part  of  the 
system/subsystem  acquisition  process.  This  subtask  should  consider 
the  defined  system  acquisition  process  from  the  perspective  of  scope, 
applicability,  process,  and  variations  of  implementation. 

a.  Scone.  The  system  acquisition  process  start  with  the  ini¬ 
tial  mission  element  need  statement  (MENS)  or  other 
equivalent  operational  capability  requirements  statement. 
The  process  continues  through  program  go  ahead,  direction, 
and  development  to  operational  deployment  and  life  cycle 
support.  This  total  span  would  be  considered  for  impact  on 
software  acquisition. 


4 


b.  Applicability.  The  System  Acquisition  Process  is  applied  in 
a  wide  range  of  systems  which  include  software.  These  range 
from  systems  of  systems,  to  functional  subsystems  such  as 
radar,  sonar,  communications,  fire  control,  electronic  war¬ 
fare  (EW)  and  other  systems.  In  addition,  major  modifica¬ 
tions  to  existing  defense  systems  are  implemented  within  the 
system  acquisition  process.  This  subtask  would  examine  this 
wide  range  of  applications  to  identify  opportunities  for 
improving  the  process. 

c.  Process.  The  System  Acquisition  Process  consists  of  several 
phases  and  steps  within  these  phases.  This  subtask  would 
formulate  a  model  of  the  phases  and  steps  to  focus  on  thr 
identify  the  activities  and  products  of  this  process  whic 
impact  the  software  acquisition  and  development. 

d.  Terms.  A  set  of  uniform  acquisition  definitions  and  term 
would  be  identified  and  applied  to  provide  consistent  at 
effective  communication  of  the  need  and  opportunities  t 
improve  the  process.  It  is  intended  that  this  specific 
activity  would  implement  the  recommendations  of  the  Defense 
Science  Board  (DSB)  regarding  promulgation  of  uniform  Mis¬ 
sion  Critical  Computer  Resource  (MCCR)  terminology. 

2. 1.1. 2  Subtask  A. 2  Impacts  of  Acquisition  Process.  This  sub¬ 
task  should  closely  review  the  System  Acquisition  Process,  as  defined 
and  considered  in  Subtask  A.l,  for  impacts  on  the  software  acquisi¬ 
tion  process  and  activities.  The  purpose  of  this  subtask  would  be  to 
systematically  identify  the  decision  points  and  specific  decisions 
and  evolving  requirements  definitions  which  offer  opportunities  to 
incorporate  a  software  perspective  in  the  process.  A  review  for 
appropriateness,  adequacy  and  effectiveness  of  the  various  software 
policies  and  their  implementation  by  the  Defense  Acquisition  Regula¬ 
tion  (DAR)  and  Federal  Acquisition  Regulation  (FAR),  DoD  Directives, 
Instructions,  and  including  Service  implementing  regulations  and  pro¬ 
cedures.  This  review  should  specifically  include  examination  and 
consideration  of  DoD  rights  in  data  and  computer  software  clauses  and 
data  acquisition  approaches.  This  is  a  necessary  step  to  avoid  miss-  - 
ing  otherwise  invisible  opportunities  to  improve  the  defense  software 
acquisition  process.  The  need  for  both  earlier  involvement  and 
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operational /support  considerations  may  be  surfaced  in  this  manner. 
Further,  this  review  should  include  a  review  of  current  approaches  to 
protection  of  software  including  proprietary,  classification,  and 
foreign  export  issues.  In  particular,  STARS  needs  early  recommenda¬ 
tions  in  this  area  for  its  own  use. 

2. 1.1. 3  Subtask  A. 3  Software  Activities.  The  intent  of  this 
subtask  should  be  to  identify  and  define  the  software  activities 
which  must  be  completed  as  part  of  the  system  acquisition  process. 
Contractual  vehicles,  policies,  regulations  and  standards,  and  the 
implementation  thereof ,*  management  and  contracting  acquisition  tools 
and  data  bases  that  could  be  expanded  to  improve  the  software 
acquisition  process  would  be  identified  and  assessed.  This  subtask 
should  review  the  findings  and  recommendations  listed  in  the  Final 
Report  of  the  Defense  Science  Board  Task  Force  on  Embedded  Computer 
Resources  (ECR)  Acquisition  and  Management  dated  November  1982. 
Those  problems,  deficiencies,  impediments,  and  restrictions  which  are 
identified  would  constitute  candidate  areas  where  actions  can  be 
direct ed. 

2. 1.1. 4  Subtask  A. 4  Specific  Issues  and  Opportunities.  The 
candidates  identified  in  Subtask  A. 3  should  be  expanded  into  specific 
issues  and  opportunities  for  improvement.  These  issues  and  opportun¬ 
ities  would  be  considered  and  expressed  in  terms  of  potential  payoff 
for  changing  the  process.  Additionally,  where  applicable,  recommen¬ 
dations  would  be  prepared  to  institute  contract  incentives  to  improve 
productivity  and  software  engineering  practices,  to  reward  contrac¬ 
tors  for  developing  and  using  appropriate  tools  and  for  developing  a 
high  quality  software  product. 


*It  should  be  noted  that  each  service  implements  these  policies  and 
regulations  in  their  own  way  under  the  broad  policy  guidance  of  DoD 
Directive  and  Instructions. 
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2.2  B.  Implement  Acquisition  Improvements  (Task  2) 

2.2.1  Purpose 

The  purpose  of  this  task  should  be  to  provide  an  orderly 
approach  for  instituting  both  near-term  and  long-term  improvements  in 
the  acquisition  process.  It  would  address  the  application  of  new 
contracting  and  business  approaches  and  new  technology  (tools  and 
methods ). 

2.2.2  Strategy 

This  task  would  review  both  the  candidate  areas  for  improvement 
developed  under  Task  1  and  suggested  improvements  received  from  other 
sources  within  the  government,  industry,  and  the  academic  community. 
An  essential  element  of  this  review  would  be  to  identify  which 
improvements  are  attainable  within  the  current  acquisition  policies 
and  regulations,*  and  which  improvements  are  not. 

Alternative  solutions  for  each  candidate  opportunity  would  be 
identified  and  evaluated.  The  "best”  candidate  should  be  selected, 
and  measurement  criteria  should  be  identified  to  evaluate  the  impact 
of  implementing  the  change.  An  overall  plan  would  be  established  for 
instituting  each  change  which  identifies  cost,  schedule  and  the  pro¬ 
cess  for  implementing  the  improvements.  Each  plan  must  also  provide 
a  means  for  assessing  the  results  of  implemented  changes  and  using 
the  information  acquired  to  adjust  the  process  as  necessary. 

It  must  be  noted  that  the  acquisition  process  would  be  incremen¬ 
tally  changed  due  to  changing  software  technology  and  its  impact  on 
information  management.  The  need  for  change  would  be  recognized  by 
government  observation  of  the  results  of  reduced  acquisition 
schedules  and  by  industry  recommendations  for  changes  that  would 

^Improvements  which  are  possible  through  proper  education  of  either 
or  both  government  and  industry  personnel. 
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improve  both  software  quality  and  productivity.  An  approach  to  pro¬ 
tection  of  software  should  be  established. 

2.2.3  Examples  of  Candidate  Near-Term  Improvements 

1.  The  government  has  Government  Furnished  Property/Government 
Furnished  Equipment  (GFP/GFE)  software  tools  applicable  and 
already  being  used  on  procurements.  It  is  now  practical  to 
send  a  magnetic  tape  containing  the  GFP/GFE  tools  with  the 
RFP.  This  would  result  in  more  accurate  cost  and  schedule 
responses  since  the  contractor  could  perform  a  preliminary 
evaluation  of  the  tools  during  the  proposal  effort. 
Enhanced  or  improved  tools  might  subsequently  be  provided 
GFP/GFE  throughout  the  contract.  Specific  examples  of 
GFP/GFE  are  as  follows: 

a.  Jovial  compiler 

b.  Software  development  tool  sets  (linkers,  loaders). 

2.  Rapid  prototyping  of  new,  first-time,  software  could  be  used 
very  early  in  the  acquisition  phase.  This  could  be  before 
or  concurrent  with  the  concept  definition  phase.  The  payoff 
would  be  a  quick  refinement  of  the  requirements  and  an  indi¬ 
cation  of  feasibility  and  risk.  The  acquisition  approach 
would  be  parallel  awards  based  on  quick  reaction  proposals 
an  evaluations.  The  revolutionary  concept  would  be  that  the 
prototype  software  would  be  truly  a  throw-away  item  (similar 
to  many  hardware  prototypes). 

3.  Innovative  acquisition  strategies  have  already  been  used  in 
contracts  issued  under  the  DoD-manuf acturing  Technology  Pro¬ 
gram  (MANTECH)  and  the  Industrial  Modernization  Incentive 
Progros  (IMIP).  These  new,  innovative  contracting  stra¬ 
tegies  and  business  approaches  should  be  tested,  evaluated 
and  publicized  and  expanded  to  include  the  acquisition  of 
software.  Some  of  these  strategies  involve  shared  cost, 
innovative  licensing,  and  protection  of  both  the  governments 
and  industry's  rights. 

4.  Increased  emphasis  could  be  directed  to  have  the  Progran 
Managers  address  the  systems  and  software  engineering  issues 
during  the  DSARC  process  on  major  systems. 

5.  Expanded  education  of  the  Contracting  Community  (Contracting 
Officers,  Data  Managers,  Defense  Contract  Administrative 
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Services  (DGAS)  etc.)  on  software  acquisition  concerns  and 
issues  could  immediately  help  to  improve  and  accelerate  the 
acquisition  process. 

2.2.4  Examples  of  Candidate  Long-Term  Improvements 

1.  As  GFP/GFE  tool  sets  become  increasingly  available,  contract 
language  needs  to  better  convey  their  intended  use.  In  the 
case  where  the  government  has  a  logistic  plan  for  using  a 
specific  tool  6et  for  procurred  software:  the  RFP  should 
specify  the  tool  set  or  GFP/GFE;  the  contractor  should  be 
given  the  option  of  using  the  GFP/GFE  tools  or  using  "in- 
house"  tools  for  development;  the  RFP  and  contract  should 
call  out  that  final  delivery  (block  deliveries)  will  be  made 
using  the  GFE/GFP  tool  set.  This  would  provide  government 
logistic  capability  and  maximize  contractor  productivity. 

2.  Traditional  request  for  proposals  (RFP)  call  for  a  software 
Preliminary  Design  REview  (PDR)  30  to  90  days  after  award. 
When  Ada  and  its  associated  methodologies  are  used,  more 
"front  end"  time  is  required.  There  will,  however,  be  a 
long-term  payoff  for  the  additional  "front  end"  effort.  The 
RFP  and  contract  need  to  reflect  this  fact. 

3.  A  review  and  modification  of  IR&D  rules  to  encourage  useful 
software  projects  which  incorporate  new  methods  and  techno¬ 
logical  breakthroughs  such  as  Ada,  VHSIC,  Artificial  Intel¬ 
ligence  (AI),  and  support  environments  can  be  used  to 
improve  the  software  acquisition  process. 

2.3  C.  Access  Impact  of  New  Technology  on  Systems  (Task  3) 


2.3.1  Purpose 

The  purpose  of  this  task  should  be  to  determine  the  impact  of 
new  technology  on  systems  being  acquired.  This  would  be  a  three-part 
task  focusing  on  current  and  emerging  technology.  The  objective  of 
this  task  would  be  to  obtain: 

1.  A  detailed  compendium  of  reward/risk  factors  associated  with 
emerging  technology. 

2.  Descriptive  summaries  of  lessons  learned  while  applying 
current  technologies. 


3.  A  model  for  transitioning  software  related  technology  into 
nev  acquisition  programs. 

2. 3. 1.1  Subtask  C.l.  Conduct  analyses  of  emerging  technologies 
to  determine  "revard/risk  factors"  for  acquisition  programs  preparing 
to  use  these  technologies.  The  purpose  of  this  segment  would  be  to 
assess  new  technology  rewards  in  terms  of:  shorter  development 
period,  increased  programmer  productivity,  improved  software  quality 
and  reliability,  lower  life  cycle  cost,  enhanced  software  supporta- 
bility  and  adaptability,  and  other  factors.  In  liability,  start¬ 
up/front  end  cost,  support  availability,  and  other  factors  will  be 
identified  and  quantified. 

The  following  are  a  partial  list  of  emerging  technologies  which 
are  candidates  for  this  research: 

a.  Ada/Ada  environments 

b.  VHSIC  and  near  VHSIC  products 

c.  Artificial  intelligence  and  associated  languages,  e.g.,  PRO¬ 
LOG 

d.  Mew  computer  architectures 

The  planned  output  would  include  a  compilation  of  revard/risk 
factors.  *  The  resulting  data  would  be  provided  to  government  and 
industry  for  use  in  future  acquisition/development  strategies  and 
system  design  trade  studies. 

2. 3. 1.2  Subtask  C.2.  Conduct  research  on  a  number  of  ongoing 
programs  using  state-of-the-art  technology  to  document  acquisition 
lessons  learned. 


^The  list  of  revard/risk  factors  must  be  continually  updated  and  kept 
current  in  order  to  be  a  useful  document. 
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The  following  technologies  ere  candidates  for  this  subtask 
research: 


a.  Design  automation:  automated  software  design  programs,  com¬ 
puter  assisted  design,  computer  assisted  manufacturing  and 
other  evolving  computer  assisted  functions. 

b.  Networking:  assess  success/failure  of  system  control  philo¬ 
sophies,  protocols,  contention  avoidance  approaches, 
textual /graphic  information  optimization  and  other  features. 

c.  Distributed  processing:  identify  architectural  constraints, 
system  control  features,  fail  soft,  fail  safe  methodologies, 
and  system  optimization. 

d.  Mass  storage  technologies:  describe  benefits,  spectrum  of 
use,  supportability ,  durability,  maintainability,  reliabil¬ 
ity,  and  other  features. 

e.  Transportable  software:  define  specification  features 
enhancing  transportability,  outline  documentation  require¬ 
ments,  and  describe  approaches  to  reduce  risk  when  reusing 
applications  and  support  software. 

2. 3. 1.3  Subtask  C.4.  Conduct  research  on  past  programs  for 
examples  of  highly  successful/unsuccessful  software  technology 
transfer.  Document  factors  enhancing  the  technology  transfer  pro¬ 
cess. 


Using  information  gathered  in  the  above  research,  develop  model 
contracts  for  software  technology  transition.  Disseminate  this 
information  to  interested  government  agencies  and  industry. 

2.4  D.  Improve  Acquisition  Bv  Using  New  Technologies  (Task  4) 

2.4.1  Purpose 

Emerging  and  available  technologies  should  be  analyzed  to  deter¬ 
mine  their  applicability  to  the  process  of  systems /software  acquisi¬ 
tion.  Examples  of  the  application  of  these  technologies  to  the 
acquisition  process  are: 
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1.  Electronic  information  transfer  (in  lieu  of  bard  copy) 
a*  Proposals 

b.  Technical  order  data 

c.  Engineering  data 

d.  Software  documentation. 

A  survey  should  be  conducted  of  the  automated  management  tools  now 
available*  Determine  the  feasibility  of  integrating  these  tools  to 
operate  as  a  single  data  base  for  a  given  system  being  acquired. 
These  tools  include,  but  are  not  limited  to: 

Pert 

Gantt 

CSCS/C 

Software  releases 

Hardware  releases. 

Several  actual  system  acquisition  programs  should  be  instru¬ 
mented.  Instrumentation  should  be  applied  from  DoD  requirements  gen¬ 
eration,  at  least  through  acceptance/delivery  of  the  first  production 
item.  Instrumentation  well  into  the  system  life  cycle  would  be 
desirable. 

The  data  obtained  from  such  instrumentation  would  be  used  to 
derive  quantitative  parameters  useful  in  the  system  acquisition  pro¬ 
cess.  Examples  are: 

o  IV&V — is  the  real  value  worth  the  cost? 

o  Can  success /failure  of  a  system  acquisition  process  be  quan¬ 
tified?  Predicted?  When? 

o  Cost  effectiveness  of  new  DARs  &  FARs  changes. 

o  Software  productivity  measurements. 
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o  Software  coat  modeling  effectiveness/accuracy. 

o  Software  error  disposition  (bow  many  are  fixed,  forgotten, 
worked  around,  not  discovered  until  after  system  is 
fielded?) 

o  Ultimate  compliance  of  the  produced  system  with  the  original 
performance  specification  (system  specs.) 

An  appropriate  DoD  of f ice /activity  should  be  identified  to  act  as  a 
focal  point  for  both  the  implementation  and  assessment  of  the 
success /failure  of  efforts  to  improve  the  systems  acquisition  process 
by  application  of  new  technology. 

2.5  E.  Establish  a  Software  Acquisition  Panel  (Task  5) 

It  is  recommended  that  an  Acquisition  Panel  be  established  by 
the  Under  Secretary  of  Defense  for  Research  and  Engineering  to  serve 
as  the  DoD  focal  point  for  implementing  measures  to  improve  and  unify 
policy,  practices,  and  procedures  related  to  the  acquisition  of 
Defense  systems  employing  Mission  Critical  Computer  Resources.  It  is 
also  recommended  that  the  Acquisition  Panel  be  responsible  to  the  OSD 
entity  responsible  for  overall  management  of  Mission  Critical  Com¬ 
puter  Resources  (MCCR)  within  the  Department  of  Defense  (such  as  the 
Defense  Computer  Resources  Board  proposed  in  the  current  draft  of  DoD 
Directive  5000.29).  It  is  recommended  that  this  panel  be  composed  of 
members  representing  various  DoD  elements  significantly  impacted  by 
or  having  significant  impact  upon  Defense  software  acquisition.  A 
proposed  organizational  arrangement  depicted  in  Figure  1  is  discussed 
below  in  detail. 

It  is  intended  that  the  Software  Acquisition  Panel  facilitate 
sound  and  logical  business  and  contract  practices  associated  with  all 
facets  of  Defense  software  acquisition;  and  to  provide  appropriate 
incentives  to  encourage  enhanced  contractor  participation,  produc¬ 
tivity,  software  quality,  and  software  reliability.  In  order  to 
implement  these  objectives,  the  Acquisition  Panel  would  recommend 
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DOCK  WIDE 
ALL  SUGGESTIONS 
FOR  ACQUISITION 
IMPROVEMENTS 


appropriate  acquisition  policy,  contract  incentive  mechanisms,  and 
related  guidelines  to  encourage  contractor  participation  in  Defense 
software  efforts;  encourage  use  of  modern  software  practices  and 
appropriate  tools;  encourage  development  of  reusable  software  com¬ 
ponents;  and  facilitate  optimization  of  life  cycle  costs. 


ii  1  ‘1*1  ■!  H'i  1 1  i4  vl  Mrl  m  i  FI  *jmj£  hI4! 


The  Software  Acquisition  Panel  would  be  responsible  for: 

a)  Identifying  ways  in  which  the  Defense  System  Acquisition 
Review  Council  review  process  could  be  strengthened  and  made 
more  effective  with  regard  to  Defense  software  acquisition; 

b)  Identifying  those  aspects  of  the  Defense  Acquisition  Regula¬ 
tion  (DAR)  [or  its  successor  Federal  Acquisition  Regulation 
(FAR)]  which  are  considered  to  be  an  impediment  to  achieving 
the  goals  and  objectives  of  the  software  initiative  and  its 
related  acquisition  goals  and  recommending  appropriate 
changes ; 

c)  Identifying  and  recommending  appropriate  actions  for  improv¬ 
ing  Defense  software  acquisition  procedures,  processes,  and 
related  directives  or  instructions. 

d)  Management  of  software  acquisition  tasks  as  well  as  other 
software  initiative  efforts  impacting  the  software  acquisi¬ 
tion  process. 

Recommendations  or  requests  for  implementation  of  specific 
improvement  measures  would  be  forwarded  by  the  Acquisition  Panel  to 
the  appropriate  implementation  authority  after  appropriate  coordina¬ 
tion  with  the  OSD  KCCR  management  entity  discussed  above. 

It  is  recommended  that  the  Acquisition  Panel  membership  include 
a  representative  from  each  appropriate  Defense  component  acquisition 
activity  principally  responsible  for  embedded  computer  systems 
software  acquisition;  a  STARS  project  office  member;  a  member  from 
the  Office  of  the  Under  Secretary  of  Defense  for  Research  and 
Engineering  (OUSDRE)  responsible  for  Command,  Control,  Communica¬ 
tions,  and  Intelligence  (C^I);  a  member  from  the  office  of  the 
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Director,  Defense  Test  end  Evaluation;  a  technology  acquisition  spe¬ 
cialist  member  from  the  office  of  the  Director,  Defense  Test  and 
Evaluation;  a  technology  acquisition  specialist  member  approved  by 
the  ADUSDRE(R&AT);  and  a  productivity  specialist  member  approved  by 
the  ADOSDRE(AM-Productivity ) . 

2.5.2  Establishment  of  Acquisition  Panel  Working  Groups 

It  is  considered  essential  that  the  Acquisition  Panel  should 
establish  and  maintain  a  dialogue  with  representatives  of  various 
DoD,  government,  academia  and  user  activities  which  are  especially 
involved  or  impacted  by  the  Defense  software  acquisition  process,  and 
it  is  further  recommended  that  this  dialogue  be  facilitated  by  the 
Acquisition  Panel  establishing  various  working  groups  to  work  with 
and  support  the  Acquisition  panel  as  follows: 

2. 5. 2.1  Industrv/Academia/Government  Wrokine  Groups.  It  is 
considered  essential  that  industry/academia/govemment  working  groups 
be  established  related  to  relevant  areas  of  acquisition  activity  to 
facilitate  review  and  comment  when  appropriate,  and  to  provide  recom¬ 
mendations  from  those  communities  to  be  readily  considered.  Member¬ 
ship  in  one  or  more  of  these  working  groups  should  include  a 
representative  from  the  Defense  Systems  Management  College  (DSMC). 
It  is  also  recommended  that  interested  individuals  and  private  organ¬ 
izations,  industry  associations,  and  representatives  from  other 
government  agencies  be  solicited  for  such  participation. 

2. 5. 2. 2  User  Working  Groups.  It  is  recommended  that  special¬ 
ized  working  groups  be  established  specifically  to  address  concerns 
and  requirements  of  the  software  end  user  and  the  MCCR  acquisition 
communities. 
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.3  Coordination  with  the  STARS  Proiect  Office 

The  Acquisition  Panel  should  vork  in  coordination  vith  the  STARS 
program  office  regarding  STARS  identified  task  efforts,  and  task 
efforts  carried  out  by  the  Acquisition  Panel  should  be  funded  by  the 
STARS  office.  it  is  recommended  that  the  Acquisition  Panel  be 
responsible  for  management  and  oversight  of  all  acquisition  related 
activities. 

2.5.4  Coordination  with  the  Joint  Logistics  Commanders 

It  is  recommended  that  the  Acquisition  Panel  maintain  close 
liaison  and  coordination  vith  the  efforts  of  the  Joint  Logistics  Com¬ 
manders  regarding  their  efforts  to  improve  the  acquisition  of  Defense 
software.  It  is  further  recommended  that  the  representatives  on  the 
Acquisition  Panel  from  each  service  principal  acquisition  activity 
also  serve  as  the  liaison  vith  the  Joint  Logistics  Commanders /Joint 
Policy  Coordinating  Group  for  Computer  Resources  Management. 

2.5.5  Coordination  vith  the  DAR/FAR  Council 

Because  of  the  importance  of  ensuring  effective  coordination 
between  the  Acquisition  Panel  and  those  offices  responsible  for  DoD 
acquisition  policy,  it  is  recommended  that  the  Acquisition  Panel 
coordinate  closely  vith  the  Defense  Acquisition  Regulation  (DAR) 
council  and  the  Federal  Acquisition  Regulation  (FAR)  council,  and 
vith  other  appropriate  offices  vithin  OSD.  To  this  end,  the  Acquisi¬ 
tion  Panel  should  provide  a  representative  to  fully  participate  in 
DAR/FAR  council  and  subcommittee  deliberations  in  matters  affecting 
Defense  softvare  acquisitions.  It  is  further  recommended  that  pro¬ 
posed  changes  to  the  Defense  Acquisition  Regulation  (DAR)  the  fully 
coordinated  vith  the  Acquisition  Panel. 
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It  is  important  to  understand  that  the  Software  Acquisition 
Panel  has,  in  the  above  discussion,  been  considered  as  limited  to 
"software"  to  maintain  literal  consistency  with  the  scope  of  the 
software  initiative.  However,  in  view  of  the  complex  actual  inter¬ 
dependencies  and  interaction  between  software  and  embedded  computer 
hardware  in  all  phases  of  mission  critical  computer  resources 
development  this  limitation  is  considered  to  be  inappropriate  and 
artificial.  Therefore  it  is  recommended  that  serious  consideration 
be  given  to  broadening  the  scope  of  responsibility  of  the  Acquisition 
Panel  from  that  of  "software  acquisition"  to  that  of  "mission  criti¬ 
cal  computer  resource  acquisition". 

It  is  further  recommended  that  the  Acquisition  Panel  specifi¬ 
cally  undertake,  on  a  priority  basis,  the  following  measures: 

a)  ensure  that  a  uniform  definition  of  software  acquisition 
terminology  is  promulgated; 

b)  investigate,  define,  and  implement  appropriate  contract 
incentives,  guidelines,  and  business  arrangements; 

c)  define  and  implement  a  contractor  Vork-Breakdown  Structure 
reporting  and  control  system  specialized  for  Defense 
Software  acquisition  requirements ; 

d)  foster  an  improved  understanding  within  the  contracting  com¬ 
munity  regarding  complexities  involved  in  acquisition  of 
Defense  software;  and 

e)  collect  cost  and  other  data  necessary  to  maintain  improved 
understanding  and  oversight  of  acquisition  of  Defense 
software,  and  to  derive  and  validate  appropriate  Defense 
software  cost  estimation  predictive  models. 

f)  review  for  appropriateness,  adequacy  and  effectiveness  the 
implementation  of  various  software  policies  and  their  imple¬ 
mentation  in  the  Defense  Acquisition  Regulation  (DAR)  and 
Federal  Acquisition  Regulation,  DoD  directive  and  instruc¬ 
tions,  and  implementing  regulations  and  procedures.  This 
review  should  specifically  include  examination  and 


consideration  of  DoD  rights  in  data  and  computer  softvare 
and  acquisition  approaches.  Furthermore,  because  it  is  only 
through  successful  and  effective  acquisition  of  Defense 
software  in  the  future  that  the  goals  and  objectives  of 
other  softvare  initiative  task  areas  would  be  fully  real¬ 
ized,  it  is  recommended  that  the  Acquisition  Panel  be  esta¬ 
blished  as  soon  as  possible,  and  its  efforts  undertaken  on  a 
priority  basis. 


3.0  LINKAGES  TO  OTHER  TASK  AREAS 

3.1  General  Statement 

The  Acquisition  Task  Area  would  be  directly  linked  to  all  of  the 
other  task  areas  within  the  STARS  Program.  Additionally,  there  would 
be  major  cross  links  with  other  task  areas  in  the  Software  Acquisi¬ 
tion  Task  Area.  In  general,  the  Acquisition  Task  Area  would  receive 
recommendations,  proposals  and  study  results  from  the  other  task 
areas  for  use  in  improving  the  total  life-cycle  acquisition  process. 
As  required,  other  task  areas  would  work  with  the  Acquisition  Task 
Area  in  assuring  the  correct  implementation  of  proposed  changes  to 
the  software  acquisition  process. 

3.2  Specific  Relationships 

At  the  present  time,  the  specific  relationships  between  the 
Acquisition  Task  Area  and  the  other  task  areas  might  be  split  into 
two  major  categories:  a  generic  set  of  relationships,  and  a  unique 
set  of  relationships.  Examples  are  as  follows: 

1.  Generic: 

a.  Incentive  structures  -  general. 

b.  Incentive  structures  -  for  different  contractual  rela¬ 
tionships. 

c.  "Model”  contract  requirements. 

d.  A  standardized  Statement  of  Work  (SOW). 

e.  A  definition  of  all  aspects  of  the  software  acquisition  pro¬ 
cess. 

2.  Unique 

a.  Inputs  on  manpower  and  training  needs  for  the  Human 
Resources  Task  Area. 
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b.  Identification  of  measurement /me trie  parameters  for  use 
by  the  Measurements  Task  Area. 

3.3  STARS  Program  R&D  Products 

The  Acquisition  Task  Area  should  act  as  the  progrmn  focal  point 
for  "field"  test  and  evaluation  of  all  acquisition-related  products 
generated  by  the  other  task  areas.  Results  of  the  actual  testing  in 
the  field  (that  is  at  such  on-site  locations  as  the  AFPROs,  NAVPROs, 
and  DCASs,  etc.)  would  subsequently  be  feedback  to  the  specific  task 
area  for  further  study  and  analysis,  modif ications,  updates,  etc.,  as 
required. 
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4.0  EFFORT 


4.1  Effort  By  Activities 

1.  The  support  efforts  identified  in  Section  2  will  be  per¬ 
formed  by  contractors  yet  to  be  determined. 

2.  Acquisition-related  research  tasks  vill  build  upon  the 
current  technology  baseline  and  the  applicable  outputs  of 
the  software  initiative  workshop.  Additional  tasks  will  be 
identified  as  the  end  of  FT83.  It  is  expected  that  these 
tasks  will  be  formulated  from  multiple  sources,  including 
the  initial  meetings  of  the  Acquisition  Oversight  Panel. 

4.2  Schedule/Milestones  (Proposed) 

Figure  2  presents  a  milestone  chart  for  the  five  Acquisition  Area 
tasks.  Specific  events  associated  with  operations  of  the  Acquisition 
Panel  are  given  below. 


EVENTS  FY83 

1.  Acquisition  Panel  Charter  Prepared  Apr 

2.  Acquisition  Panel  Membership  Established.  Apr 

3.  1st  Meeting  of  Acquisition  Panel*  TBD 

4.  1 st  FT  Review  Report  Acquisition  Process 

Findings.  Sept 

5.  1st  FT  Review  Report  Technology  Transfer 

and  Insertion.  Sept 

6.  1st  FT  Planning  Document  Prepared  Sept 

7.  Acquisition  Panel  Software  Initiative 

"Background"  Document  Generated  Sept 
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Chart  for  Acquisition  Area  Tasks 


events 


sm  is  nss 


1»  Periodic  Meetings  of  Acquisition  Panel 
(frequently  to  be  established) 

2.  Priority  Action  Acquisition 
Process  Issue  Report 

3.  FT  Review  Report  of  Acquisition 
Process  Findings 

A*  FT  Review  Report  Technology 
Transfers  and  Insertions 


TBD 


As  Required 


Annually /FT 
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Fiscal  Tear  Planning  Document 


Annually /FT 
September  of  each  FT 


5.0  OPPORTUNITIES 


5*1  Review  Onao ioa  Initiative!  and  Programs  Such  as  tbe  Following 

DoD'a  Acquisition  Improvement  Initiatives  to  improve  operational 
readiness  o£  our  weapon  systems,  the  IDA/OSD  R&M  Improvement  Study 
that  addresses  artificial  intelligence,  and  the  Industrial  Modernisa¬ 
tion  Incentives  Program  that  is  addressing  software  productivity. 

5.2  Information  Resources 

1.  Embedded  Computer  Resources  References  (see  references) 

2.  GAO 

1980  ADP  Bibliography 

1981/2  ADP  Bibliography  Topics  (unpublished) 

GAO  Report:  "Wider  Use  of  Better  Computer  Software  Technol¬ 
ogy  Can  Improve  Management  Control  and  Reduce  Costs"  dated 
April  29,  1980. 

3.  Deputy  Secretary  of  Defense  Memo  dated  April  30,  1981: 

"Improving  the  Acquisition  Process." 

4.  DoD  "Embedded  Computer  Resources  Standardization  Pro gran 
Plan,"  (Draft)  dated  September  15,  1982. 

5.  "Usability  of  Military  Standards  for  the  Maintenance  of 
Embedded  Computer  Software,"  Normal  F.  Schneidewind,  June 
1982. 

5»3  Current  Activities 

1.  Joint  Logistic  Commanders,  Joint  Policy  Coordination  Group 
on  Computer  Resources  Management  (JLC,  JPCG-CRM). 

2.  Electronic  Industries  Association  (EIA)  Review  of  Proposed 
ECRS  Standards. 

3.  Embedded  Computer  Resources  Standardization  Program. 

4.  Industrial  Modernization  Progros. 
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6.0  EMBEDDED  COMPUTER  RESOURCES  REFEREN CES 


6.1  DoD  Directives.  Instructions  and  Standards 

1.  DoDD  4105.55,  "Selection  and  Acquisition  of  Automatic  Data 
Processing  Resources,"  dated  19  May  1972,  incl.  Changes  1,2, 
and  3 

2.  DoDD  4120.3,  "Defense  Standardization  and  Specification  Pro- 
gran,"  dated  10  February  1979 

3.  DoDD  4120.18,  "Metric  System  of  Measurement,"  dated  28  Janu¬ 
ary  1980 

4.  DoDI  4120.20  "Development  and  Use  of  Hon-Goverament  Specifi¬ 
cations  and  Standards,"  dated  28  December  1976 

5.  DoDD  4120.21,  "Specifications  and  Standards  Application," 
dated  9  April  1977 

6.  DoDD  4155.1,  "Quality  Program,"  dated  10  August  1978,  incl. 
Change  1 

7.  DoDD  5000.1,  "Major  System  Acquisitions"  dated  19  March  1980 

8.  DoDI  5000.2,  "Major  System  Acquisition  Procedures,"  dated  19 
March  1980 

9.  DoDD  5000.3,  "Test  and  Evaluation,"  dated  26  December  1979 

10.  DoDD  5000.28,  "Design  to  Cost,"  dated  23  May  1975 

11.  DoDD  5000.29,  "Management  of  Computer  Resources  in  Major 
Defense  Systems,"  dated  26  April  1976,  incl.  Change  1  (being 
revised) 

12.  DoDI  5000.31,  "Interim  List  of  DoD  Approved  High  Order  Pro¬ 
gramming  Languages  (HOLs),"  dated  24  November  1976  (Revision 
in  final  coordination) 

13.  DoDD  5000.37,  "Acquisition  and  Distribution  of  Commercial 
Products  (ADCP),"  dated  29  September  1978 

14.  DoDD  5000.39,  "Acquisition  and  Management  of  Integrated 
Logistic  Support  for  Systems  and  Equipment,”  dated  17  Janu¬ 
ary  1980 
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dated  8 


15.  DoDD  5000.40,  "Reliability  and  Maintainability," 

July  1980 

16.  DoDI  5000.5z,  "Instruction  Set  Architecture  (ISA)  Standardi¬ 
zation  Policy  for  Embedded  Computers,"  (In  final  coordina¬ 
tion) 

17.  DoDD  5010.12,  "Management  of  Technical  Data,"  dated  5 
December  1968,  incl.  Change  1 

18.  DoDD  5010.19,  "Configuration  Management,"  dated  1  May  1979 

19.  DoDD  5100.40,  "Responsibility  for  the  Administration  of  the 
DoD  Automatic  Data  Processing  Program,"  dated  19  August 
1975,  incl.  Change  1 

20.  DoDD  5200.28,  "Security  Requirements  for  Automatic  Data  Pro¬ 
cessing  (ADP)  Systems," 

21.  DoDD  7920.1,  "Life  Cycle  Management  of  Automated  Information 
Systems  (AIS),"  dated  17  October  1978 

22.  DoDI  7920.2,  "Major  Automated  Information  Systems  Approval 
Process,”  dated  20  October  1978 

6.2  Army  Documents 

1.  Assistant  Secretary  of  the  Army  Policy  Letter,  subject: 
"Standardization  of  Embedded  Computer  Resources,"  dated  1 
July  1980 

2.  AR  18-1,  "Army  Automation  Management,"  dated  15  August  1980 

3.  AR  18-12,  "Catalog  of  Standard  Data  Elements  and  Codes," 
dated  29  March  1974 

4.  AR  70-1,  "Army  Research,  Development,  and  Acquisition," 
dated  1  May  1975 

5.  AR  70-10,  "Test  and  Evaluation  during  Development  and 
Acquisition  of  Materiel,"  dated  29  August  1975 

6.  EAR COM  Reg.  70-16,  "Management  of  Computer  Resources  in  Bat¬ 
tlefield  Automated  Systems,"  dated  16  July  1979 
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7.  AR  70-27,  "Outline  Development  Plen /Development :  Plan/Army 
Prograa  Memor andum/Def enee  Progran  Hemorandum/Decieion  Coor¬ 
dinating  Paper,"  dated  17  March  1975 

8.  AR  70-29,  "Production  Teating  of  DSA-managed  Items,"  dated 
27  May  1969 

9.  AR  70-37,  "Configuration  Managenent,"  dated  1  July  1974 

10.  AR  70-38,  "Research,  Development,  Test,  and  Evaluation  of 
Materiel  for  Extreme  Climatic  Conditions,"  dated  5  May  1969 

11.  AR  71-3,  "User  Testing,"  dated  8  March  1977 

12.  AR  310-3,  "Preparation,  Coordination,  and  Approval  of 
Department  of  Army  Publications,"  dated  20  December  1968 

13.  AR  310-25,  "Dictionary  of  US  Army  Terms,"  dated  15  September 
1975 

14.  AR  380-380,  "Automated  Systems  Security,"  dated  14  October 
1977 

15.  AR  700-127,  "Integrated  Logistics  Support,"  dated  11  April 

1975 

16.  AR  702-2,  "Uniform  Quality  Control  System,"  dated  3  December 
1970 

17.  AR  702-3,  "Army  Materiel  Reliability,  Availability,  and 
Maintainability,"  dated  15  November  1976 

18.  AR  702-4,  "Procurement  Quality  Assurance,"  dated  3  August 

1976 

19.  AR  750-1,  "Army  Materiel  Maintenance  Concepts  and  Policies,” 
dated  1  April  1978 

20.  AR  1000-1,  "Basic  Policies  for  Systems  Acquisition,”  dated  1 
May  1981 

21.  Technical  Bulletin  18-115,  "Army  Information  Processing 
Standards  (AIPS),"  dated  3  July  1980 
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6.3 


1.  SECNAVINST  3560.1,  "Tactical  Digital  Systems  Documentation 
Standards,"  dated  8  August  1974 

2.  SECNAVINST  5000. 1A,  "System  Acquisition  in  the  Department  of 
the  Navy,”  dated  17  November  1978 

3.  SECNAVINST  5200.32,  "Management  of  Embedded  Computer 
Resources  in  the  Department  of  the  Navy  Systems,"  dated  11 
June  1979 

4.  SECNAVINST  5231.1,  "Management  of  Automated  Data  Systems 
Development,"  dated  25  February. 

5.  SECNAVINST  5233. 1A,  C-l,  "Department  of  the  Navy  Automated 
Data  System  Documentation  Standards,"  dated  30  August  1974 

6.  WS-8506,  "Requirements  for  Digital  Computer  Pro gras  Documen¬ 
tation,”  dated  1  November  1971 

7.  TADSTAND  2,  "Standard  Requirements  for  Tactical  Digital  Com¬ 
puter  Program  Documentation, "  dated  1  November  1974 

8.  TADSTAND  3,  "Standard  Requirements  for  Inter-digital  Proces¬ 
sor  Interface  Documentation,"  dated  5  November  1974 

9.  TADSTAND  9,  "Software  Quality  Testing  Criteria  Standard  for 
Tactical  Digital  Systems,"  date  18  August  1978 

10.  TADSTAND  A,  "Standard  Definitions  for  Embedded  Computer 
Resources  in  Tactical  Digital  Systems,"  dated  2  July  1980 

11.  TADSTAND  B,  "Standard  Embedded  Computers,  Computer  Peri¬ 
pherals,  and  Input/Output  Interfaces,"  dated  2  July  1980 


12.  TADSTAND  C,  "Computer  Programing  Language  Standardization 
Policy  for  Tactical  Digital  Systems,"  dated  2  July  1980 


13.  TADSTAND  D,  "Reserve  Capacity  Requirements  for  Tactical 
Digital  Systems,"  dated  2  July  1980 


6.4  Air  Force  Documents 


l 

i 


1 


AFR  57-4,  "Modification  Program  Approval,"  dated  15  December 
1977,  incl.  Change  1;  AFSC  Sup.  1,  dated  1  April  1974 
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2*  AFR  65-3,  "Configuration  Management,"  revised  1  September 
1974;  AFSC  Sup.  1,  dated  25  July  1975 

3.  AFR  80-14,  "Teat  and  Evaluation,”  dated  19  July  1976;  AFSC 
Sup.  1,  dated  3  January  1977 

4.  AFR  122-9,  "The  Nuclear  Safety  Cross-Check  Analysis  and  Cer¬ 
tification  Program  for  Weapon  Systems  Software,"  dated  22 
October  1976;  AFSC  Sup.  1,  dated  22  March  1977 

5.  AFR  122-10,  "Nuclear  Weapon  System  Safety  Design  and  Evalua¬ 
tion  Criteria,"  dated  27  November  1978 

6.  AFR  300-8,  "Security  Requirements  for  Automatic  Data  Pro¬ 
cessing  Systems  (ADPS),"  dated  2  June  1974 

7.  AFR  300-10,  "Computer  Programing  Languages,"  dated  15 
December  1976 

8.  AFR  800-2,  "Acquisition  Program  Management,"  dated  14 
November  1977 

9.  AFLCR  800-12,  "Acquisition  of  Support  Equipment,"  dated  20 
May  1974 

10.  AFR  800-14,  V.I,  "Management  of  Computer  Resources  in  Sys¬ 
tems,"  dated  12  September  1975;  AFLC  Sup.  1,  dated  15 
October  1976;  AFSC  Sup.  1,  dated  8  August  1977;  ESD  Sup.  1, 
dated  8  August  1977 

11.  AFR  800-14,  V.II,  "Acquisition  and  Support  Procedures  for 
Computer  Resources  in  Systems,”  dated  26  September  1975; 
AFLC  Sup.  1,  dated  18  October  1976;  ESD  Sup.  1,  dated  25 
November  1975 

12.  AFR  800-19,  "System  or  Equipment  Turnover,"  dated  27  May 
1975 

13.  AFLCR  800-21,  "Management  and  Support  Procedures  for  Com¬ 
puter  Resources  UBed  in  Defense  Systems,"  dated  4  January 
1980 

14.  AFR  800-28,  "Air  Force  Policy  on  Avionics  Acquisition  and 
Support,”  dated  11  September  1978 
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6.5  Standardization  Documents 


1.  DoD-STD-lOOC,  "Engineering  Drawing  Practices,"  revised  22 
December  1978;  Notice  1,  dated  30  April  1980 

2.  MIL-STD-109B,  "Quality  Assurance  Terms  and  Definitions," 
dated  4  April  1969 

3.  MIL-STD-143B,  "Order  of  Precedence  for  the  Selection  of 
Standards  and  Specifications,"  dated  12  November  1969 

4.  MIL-STD-470,  "Maintainability  Program  Requirements  (for  Sys¬ 
tems  and  Equipment),"  dated  21  March  1966 

5.  DoD-STD-480A ,  "Configuration  Control  -  Engineering  Changes, 
Deviations  and  Waivers,"  dated  12  April  1978 

6.  MIL-STD-481A,  "Configuration  Control  -  Engineering  Changes, 
Deviations  and  Waivers  (Short  Form),"  dated  18  October  1972 

7.  MIL-STD-482A,  "Configuration  Status  Accounting  Data  Elements 
and  Related  Features,"  dated  1  April  1974 

8.  MIL-STD-483  ( USAF ) ,  "Configuration  Management  Practices  for 
Systems,  Equipment,  Munitions  and  Computer  Software,” 
revised  1  June  1971;  Notice  2,  dated  21  March  1979 

9.  MIL-STD-490,  "Specification  Practices,"  revised  18  May  1972 

10.  MIL-STD-721B,  "Definitions  of  Effectiveness  Terms  for  Relia¬ 
bility,  Maintainability,  Human  Factors  and  Safety,"  revised 
10  March  1970 

11.  MIL-STD-756A,  "Reliability  Prediction,"  dated  15  May  1963 

12.  MIL-STD-757,  "Reliability  Evaluation  from  Demonstration 
Data,"  dated  19  June  1964 

13.  MIL-STD-785B,  "Reliability  Program  for  Systems  and  Equipment 
Development  and  Production,"  revised  15  September  1980 

14.  MIL-STD-1472B,  "Human  Engineering  Design  Criteria  for  Mili¬ 
tary  Systems,  Equipments  and  Facilities,"  revised  10  May 
1976;  Notice  2,  dated  10  May  1978 
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15.  MIL-STD-1521A  (USAF),  "Technical  Reviews  and  Audits  for  Sys¬ 
tems  Equipments  and  Computer  Progranst"  dated  1  June  1976; 
Notice  1,  dated  27  September  1978 

16.  MIL-STD-1553B,  "Aircraft  Internal  Time  Division 
Command /Response  Multiplex  Data  Bus,"  dated  21  September 
1978;  Notice  1,  dated  12  February  1980 

17.  MIL-STD-1589B  (OSAF),  "JOVIAL  (J73),"  dated  6  June  1980 

18.  MIL-STD-1679  (NAVY),  "Weapon  System  Software  Development," 
dated  1  December  1978 

19.  MIL-STD-17 50A  (USAF),  "Sixteen-Bit  Computer  Instruction  Set 
Architecture,"  dated  2  July  1980 

20.  MIL-STD-17 53 ,  "FORTRAN,  DoD  Supplement  to  American  National 
Standard  X3. 9-1978,"  dated  9  November  1978 

21.  MIL-STD-1815,  "Ada  Programming  Language,"  dated  10  December 
1980 

22.  MIL-STD-1862 ,  "Instruction  Set  Architecture  for  the  Military 
Computer  Family,"  dated  28  May  1980 

23.  DoD  Standard  7935. 1-S,  "Automated  Data  Systems  Documentation 
Standards, "  dated  13  September  1977 

24.  MIL-Q-9858A,  "Quality  Program  Requirements,”  dated  16 
December  1963 

25.  MIL-S-52779A  (AD)  "Software  Quality  Assurance  Program 
Requirements,"  dated  1  August  1979 

26.  ANSI/IEEE  Std,  416-78  "Standard  ATLAS  Test  Language" 

27.  FIPS  Pub  11-1,  "Dictionary  for  Information  Processing," 
dated  30  September  1977 

28.  FIPS  Pub  24,  "Flowchart  Symbols  and  their  Usage  in  Informa¬ 
tion  Processing,"  dated  30  June  1973 

29.  FIPs  Pub  30,  "Software  Summary  for  Describing  Computer  Pro¬ 
grams  and  Automated  Data  Systems,"  dated  30  June  1974 

30.  FIPS  Pub  41,  "Computer  Security  Guidelines  for  Implementing 
the  Privacy  Act  of  1974,"  dated  30  May  1975 
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31.  "CMS-2A  Progranmer's  Reference  Manuals,"  M-5049  and  M-5044 
FCDSSA,  San  Diego,  CA  December  1978 

32.  "CMS-2M  Computer  Performance  Specification,"  NAVELEX 
0967LP-598-2210  October  1978 

33.  "SPL/1  Language  Reference  Manual,”  5490-163  EF;vjs,  NRL, 
Washington,  DC 

Guidelines  and  Miscellaneous  References 

1.  ASD-TR-76-11 ,  "Management  Guide  to  Avionics  Software 
Acquisition;  Vol.  1,  An  Overview  of  Software  Development  and 
Management,  (AD  A030591);  Vol.  II,  Software  Acquisition  Pro¬ 
cess  (AD  A0309392);  Vol.  Ill,  Summary  of  Software  Related 
Standards  and  Regulations  (ADA030593);  Vol.  IV,  Technical 
Aspects  Related  to  Software  Acquisition  (AD  A030594),"  June 
1976 

2.  ASD-TR-78-6,  (AD  AO 58428),  "Engineering  Guide  to  Avionics 
Software  Acquisition:  Requirements,  Specifications,  and 
Standards ” 

3.  ASD-TR-78-7,  (AD  A058429),  "Engineering  Guide  to  Avionics 
Software  Acquisition:  Reviews  and  Audits" 

4.  ASD-TR-78-8,  (AD  A059068),  "Airborne  Systems  Software 
Acquisition  Engineering  Guidebook  for  Quality  Assurance," 
November  1977 

5.  ESD-TR-75-85 ,  (AD  A016488),  "An  Air  Force  Guide  to  Monitor¬ 
ing  and  Reporting  Software  Development  Status,"  September 
1975 

6.  ESD-TR-75-91 ,  (ADA016401),  "Software  Acquisition  Management 

Guidebook:  Requirements,  Specifications  and  Standards," 

October  1975 

7.  ESD-TR-75-365 ,  (AD  A020444),  "An  Air  Force  Guide  to  Con¬ 
tracting  for  Software  Acquisition,"  January  1976 

8.  ESD-TR-76-159,  (AD  A0207051),  "An  Air  Force  Guide  to 
Software  Documentation  Requirements."  June  1976 

9.  ESD-TR-77-16 ,  (AD  A0359J4),  "Software  Acquisition  Management  • 
Guidebook:  Statement  of  Work  Preparation,"  January  1977 
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10.  ESD-TR-77-22 ,  (AD  A037115),  "Software  Acquisition  Management 
Guidebook:  Life  Cycle  Events,"  February  1977 

11.  ESD-TR-77-130,  (AD  A038234),  "Software  Acquisition  Manage¬ 
ment  Guidebook:  Software  Development  and  Maintenance  Facili¬ 
ties,"  April  1977 

12.  ESD-TR-77-254,  (AD  A047308),  "An  Air  Force  Guide  to  Computer 
Program  Configuration  Management,"  August  1977 

13.  ESD-TR-77-255,  (ADA047318),  "Software  Acquisition  Manage¬ 
ment  Guidebook:  Software  Quality  Assurance,"  August  1977 

14.  ESD-TR-77-263,  (AD  A048577) ,  "Software  Acquisition  Manage¬ 
ment  Guidebook:  Ver if ication, "  August  1977 

15.  ESD-TR-77-326 ,  (AD  A053039),  "Software  Acquisition  Manage¬ 
ment  Guidebook:  Validation  and  Certification,"  August  1977 

16.  ESD-TR-77-327 ,  (AD  AO 53 040),  "Software  Acquisition  Manage¬ 
ment  Guidebook:  Software  Maintenance,"  October  1977 

17.  ESD-TR-78-117 ,  (AD  A052567) ,  "Software  Acquisition  Manage¬ 
ment  Guidebook:  Reviews  and  Audits,"  November  1977 

18.  ESD-TR-78-139,  (AD  A055573),  "An  Air  Force  Guide  to  the  Com¬ 
puter  Progran  Development  Specification,"  March  1978 

19.  ESD-TR-78— 140,  (AD  A055574),  "Software  Acquisition  Manage¬ 
ment  Guidebook:  Software  Cost  Estimation  and  Measurement," 
March  1978 

20.  ESD-TR-78-141 ,  (AD  A055575),  "Software  Acquisition  Manage¬ 
ment  Guidebook:  Series  Overview,"  March  1978 

21.  "Tactical  Embedded  Computer  Software  Audit  Manual,"  dated  2 
May  1980  (available  from  HQ  NAVMAT-08Y) 

22.  "E1A  Configuration  Management  Bulletin  No  4-1A,  Configura¬ 
tion  Management  for  Digital  Computer  Programs  (Defini¬ 
tions),"  (available  from  Electronic  Industries  Association, 
Engineering  Department;  2001  Eye  Street,  N.W.  Washington,  DC 
20006) 

23.  "The  DACS  Glossary,  A  Bibliography  of  Software  Engineering 
Terms,"  October  1979  (available  from  Data  and  Analysis 
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Center  for  Software,  RADC/ISISI,  Griffiss  Air  Force  Base,  NY 
13441 ) 

24.  Public  Law  89-306,  89th  Congress,  H.R.  4845,  dated  30 
October  1965,  "Brook's  Bill" 
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